This won't affect skating-correction since the magnitude of acceleration is not being changed.

Not really. Some code uses only the two components, like Vector3(footDif.x, 0f, footDif.z) . It uses x and z components, which correspond to trackers to original (x y) components in this PR and trackers (y z) in the current main branch. z in the tracker coordinates corresponds to the gravity direction. That is what the fix is about.

	private fun correctUnlockedFootTracker(footPosition: Vector3, previousFootPosition: Vector3, previousFootPositionCorrected: Vector3, footVelocity: Vector3, framesUnlocked: Int): Vector3 {
		var newFootPosition = footPosition
		var footDif = footPosition - previousFootPositionCorrected
		footDif = Vector3(footDif.x, 0f, footDif.z)

This won't affect skating-correction since the magnitude of acceleration is not being changed.

Not really. Some code uses only the two components, like Vector3(footDif.x, 0f, footDif.z) . It uses x and z components, which correspond to trackers to original (x y) components in this PR and trackers (y z) in the current main branch. z in the tracker coordinates corresponds to the gravity direction. That is what the fix is about.

	private fun correctUnlockedFootTracker(footPosition: Vector3, previousFootPosition: Vector3, previousFootPositionCorrected: Vector3, footVelocity: Vector3, framesUnlocked: Int): Vector3 {
		var newFootPosition = footPosition
		var footDif = footPosition - previousFootPositionCorrected
		footDif = Vector3(footDif.x, 0f, footDif.z)

That is a positional correction, the acceleration is not used like that, I just checked. Mocap mode does use the acceleration direction though so this will help that!

@ImUrX is anything else required for this PR to be merged?

You need to wait for more reviewers

I though that two reviwers are enough. Should we ping someone to make a review?

@Stermere id don't know if the fusion does the order right, but, at least, they in the right order during packet formation.

If you like I could take the original AXES_OFFSET and apply it both to rotation and acceleration. So, it will be defined by mostly by software, not a math.

On the other hand, if the bug is in the fustion, than the firmware has to be fixed instead of tuning the server for the firmware. At least, we could define a new version of protocol. The reason is because slime wants to be a kind of opensource standard for VR.

The current acceleratoin offsets is defenetely wrong. Some code may work better now because it was tuned for the current wrong offsets. That could work for now but it can be so for a robust code evolution.